Today, we will demonstrate the workaround and mitigation for the log four J vulnerability. This vulnerability is known as CV 2021-44228. Um The uh Dell security uh update is DS A dash 2021-277. We recommend that you check up on the uh DS A uh frequently as things change.
It's DS A 2021-277 begin the remediation. We promote uh the user to root and we check the uh contents of the Etsy environment file. Um It should be empty but if it's not, that's OK. Uh Then we go to the end of the file and uh add a line that says log four J format message, no lookups.
If it's true, save the file, you have to file out again to make sure that it was uh saved properly and then uh check the uh ownership and permissions in the file. The uh file should be owned by root, root and the permission should be 644. Next, we will use a tool called log preo to uh remediate any jar files that are uh located in any of the library directors.
Um go back to the home admin the uh where the tool was stored previously. Now, the tool does need to be run as root. So uh simply run Java Jar log press and then there's only one command line argument and that's the minus minus fix argument. If you wish, you can run it without the fix and it will uh simply um find any files that uh have this vulnerability.
If you add the fix, it will fix them as well. Um We're going to check every uh subdirectory under user local um because there are um library directories uh principally user local, live and user local line 64. Um The tool takes about two minutes to run and scan all directories as it goes, it will enunciate which directory gets checked. You can see the results here.
It took about 84 seconds to scan all the live directories. It scanned 1900 directories and 21,000 files. Uh It didn't find any vulnerabilities because this uh example machine has already been mitigated. And so there's uh there's no longer any vulnerabilities mitigated that you can see the result here.
Next, we will um change to the admin user. Um This creates a new shell so that we can test the environment variable that we set up previously. We'll do this simply by printing out the environment and checking for the existence of the string log four J. And we can see that the environment variable has been set correctly.
Next, we will check the status of the machine and uh make sure that it's ready. Um For the next steps, first, we'll check the status of the services with EPNCTL status. Make sure that all the services are running. Next. We will stop the maintenance scheduler. Now, this allows us to make an additional checkpoint for safety and once the maintenance schedule has been stopped, we simply take a new checkpoint with the ad made checkpoint command.
Next, we will use status dot DPN to check the progress of the checkpoint here. You can see that it's nearly complete all 25 stripes and, and let me check again, you'll see that it is checkpoints on a production system will be not as fast. They will probably take typically 2 to 3 minutes.
Next, we will begin the remediation um by stopping the uh enterprise manager web application. This has to be done as root. So we've promoted to root next test the uh enterprise manager web app to see that it's uh next step is to stop the management console.
It's important at this point to point out that we should be using the MC server dot sh command to stop the management console, uh DPNCTL stop M CS command uh might present problems in this context. So please use MC server dot S A minus minus stop. Um This process takes a few minutes uh because the beginning of the process um creates a uh a blush backup.
Next, we'll test to see that the MC server is down. And finally, we simply restart the MC server. This will um create a new uh M CS context uh which uh takes advantage of the environment variable that we set previously. This process also takes several minutes to complete once again because of the dynamic nature of the remediation steps.
It's important to check back with DS A 2021-2 77 for the latest uh updates and remediation steps. Once the rest API services started, you can promote again to the root user so that we can start the enterprise manager web app. And finally one final test to restart the maintenance scheduler and the backup scheduler.
Now that both schedulers have been restarted, we'll make a last check of the status of all of the services. Here, we can confirm that G is up. M CS is up and both schedulers have been restarted and a final quick check of the status of the G A shows that running collect. This is all of the steps required to remediate the, the vulnerability.